home *** CD-ROM | disk | FTP | other *** search
/ TeX 1995 July / TeX CD-ROM July 1995 (Disc 1)(Walnut Creek)(1995).ISO / systems / atari / birkhahn-metafont-packed-disks / mf27-2_2e-disk2.zoo / doc.lzh / XACC.DOC < prev   
Text File  |  1990-08-05  |  19KB  |  462 lines
  1. XAcc: Ein universelles Kommunikationsprotokoll für Accessories unter GEM
  2. ========================================================================
  3.  
  4. (Version vom 14.5.1989)
  5.  
  6. [Diese Version enthält eine Änderung der Protokolldefinition gegenüber]
  7. [älteren Versionen, die die Initialisierungsprozedur betrifft. Näheres]
  8. [im Abschnitt 'Meldungen der Stufe 0'.]
  9.  
  10.  
  11.  
  12. GEM AES stellt mit den Funktionen appl_write() und appl_read() eine
  13. flexible Möglichkeit zur Kommunikation zwischen Accessories und dem
  14. jeweiligen Hauptprogramm zur Verfügung. In der Praxis entstehen dabei
  15. jedoch einige Schwierigkeiten:
  16.  
  17. - appl_write() benötigt die Identifikationsnummer (apid) des Empfängers.
  18.   Diese ist aber nur über appl_find() zu bekommen, wozu der Name des
  19.   jeweiligen Programms angegeben werden mu₧. Daher können Programme
  20.   nur mit solchen anderen Programmen kommunizieren, deren Namen sie
  21.   kennen. Au₧erdem hat appl_find() den Fehler, da₧ ein Hauptprogramm auch
  22.   nach seiner Beendung noch gefunden wird.
  23.  
  24. - Das Hauptprogramm wird nicht darüber informiert, wann ein Accessory
  25.   aufgerufen oder beendet wird. Dies wäre jedoch oft nützlich, um z.B.
  26.   Änderungen von Systemvariablen, die das Accessory stören könnten,
  27.   vor dem Start eines solchen rückgängig zu machen, oder um dem
  28.   Hauptprogramm eine Gelegenheit zu geben, Änderungen der Systemumgebung
  29.   (z.B. des Clipboards) durch das Accessory festzustellen.
  30.  
  31. - Es gibt keine genormten Meldungen zum Datenaustausch zwischen Programmen.
  32.  
  33.  
  34. Das hier vorgestellte Kommunikationsprotokoll löst alle diese Probleme.
  35. Es wurde für zwei Anwendungsarten konzipiert:
  36.  
  37. 1. Kommunikation zwischen beliebigen Programmen, die voneinander keine
  38.    Informationen haben, mit elementaren Möglichkeiten zum Datenaustausch.
  39.  
  40. 2. Kommunikation zwischen einem Hauptprogramm und speziell dazu geschriebenen
  41.    Accessories, die z.B. spezielle Hilfsfunktionen übernehmen. Das einheitliche
  42.    Protokoll stellt sicher, da₧ Programmkombinationen verschiedener Hersteller
  43.    konfliktfrei verwendet werden können.
  44.  
  45.  
  46. Dieses Protokoll beruht auf der Tatsache, da₧ das jeweilige Hauptprogramm
  47. immer die apid 0 bekommt. Zwar wird diese Eigenschaft nicht in der GEM-
  48. Dokumentation erwähnt, sie ist jedoch nach Auskunft von Digital Reearch
  49. in allen GEM-Versionen für MS-DOS und GEMDOS vorhanden. Für die Multitasking-
  50. Version X/GEM unter FlexOS kann das XAcc-Protokoll allerdings nicht ohne
  51. Änderungen verwendet werden; dort gibt es aber auch gar keine Accessories.
  52.  
  53. Eine weitere Voraussetzung ist, da₧ Programme, die dieses Protokoll nicht
  54. anwenden, die dazugehörenden Meldungen ignorieren. Jedes ordentliche
  55. GEM-Programm sollte jedoch unbekannte Meldungen ignorieren, und bis jetzt
  56. sind auch nur zwei Programme bekannt, die mit diesem Protokoll unverträglich
  57. sind.
  58.  
  59.  
  60. Verschiedene Stufen des XAcc-Protokolls:
  61. ----------------------------------------
  62.  
  63. Sowohl Accessories als auch Hauptprogramme können sehr verschiedene
  64. Anforderungen an Kommunikation mit anderen Programmen haben. Um möglichst
  65. viele Anwendungen zu unterstützen, andererseits aber 'anspruchslose'
  66. Programme nicht durch ein umfangreiches Protokoll zu kompliziert zu
  67. machen, gibt es mehrere Stufen des XAcc-Protokolls. Diese Stufen bauen
  68. aufeinander auf, d.h. ein Programm, das Stufe 2 unterstützt, mu₧ auch
  69. die Meldungen der Stufen 0 und 1 verstehen. Wenn ein Programm eine bestimmte
  70. Stufe unterstützt, mu₧ es alle dazugehörenden Meldungen ordnungsgemä₧
  71. bearbeiten.
  72.  
  73. Bisher sind drei Stufen definiert:
  74.  
  75. Stufe 0 umfa₧t nur die Identifikation, jedoch keinen Datenaustausch. Viele
  76. Accessories kommen damit aus, insbesondere solche, die nur zur Anwendung mit
  77. bestimmten Hauptprogrammen gedacht sind und ausschlie₧lich spezielle
  78. Meldungen benutzen. Aber auch für viele Hauptprogramme ist Stufe 0
  79. ausreichend.
  80.  
  81. Stufe 1 umfa₧t den Austausch von Textdaten im ASCII-Format. Die meisten
  82. Hauptprogramme fallen in diese Kategorie, aber auch Accessories, die
  83. Befehle entgegennehmen und/oder Ergebnisse produzieren.
  84.  
  85. Stufe 2 umfa₧t den Austausch von Grafikdaten in den genormten GEM-Formaten
  86. für Metafiles und Bitmap-Bildern. Hauptanwender sind natürlich Grafikprogramme
  87. aller Art, aber auch Textverarbeitungs- und Desktop-Publishing-Programme.
  88.  
  89. Weitere Stufen sind zur Zeit nicht genormt. Mögliche Datentypen für
  90. Erweiterungen wären z.B. MIDI-Daten oder Spreadsheet-Daten. Vor der
  91. Definition weiterer Stufen soll das XAcc-Protokoll erst einmal einige
  92. Zeit in der Praxis erprobt werden. Dabei wird sich auch der Bedarf für
  93. weitere Datentypen erkennen lassen.
  94.  
  95.  
  96. Meldungen im XAcc-Protokoll:
  97. ----------------------------
  98.  
  99. Das XAcc-Protokoll unterscheidet zwischen universellen Meldungen, die
  100. jedes Programm verstehen mu₧, und speziellen Meldungen, die nur für
  101. die Kommunikation zwischen bestimmten Programmen gedacht sind. Die
  102. universellen Meldungen erhalten Nummern von 0x400 bis 0x7FF, die speziellen
  103. Meldungen Werte ab 0x800. Spezielle Meldungen dürfen nur verschickt werden,
  104. wenn der Absender anhand der Identifikation des Empfängers erkannt hat, da₧
  105. dieser die Meldung verstehen wird. Im folgenden werden nur noch die
  106. universellen Meldungen behandelt.
  107. Darüber hinaus stehen natürlich auch die vom AES definierten Meldungen zur
  108. Verfügung, wobei insbesondere AC_OPEN und MN_SELECTED sinnvoll eingesetzt
  109. werden können (MN_SELECTED erfordert natürlich Informationen über den
  110. Empfänger).
  111.  
  112.  
  113. Meldungen der Stufe 0:
  114. ----------------------
  115.  
  116. ACC_ID = 0x400
  117. ACC_OPEN = 0x401
  118. ACC_CLOSE = 0x402
  119. ACC_ACC = 0x403
  120.  
  121. Die Kommunikation zwischen Accesories und Hauptprogramm läuft folgenderma₧en
  122. ab:
  123.  
  124. 1) Beim Start (und bei Beendung) eines Hauptprogramms bekommt jedes Accessory
  125.    vom AES die Meldung AC_CLOSE. Als Reaktion darauf mu₧ es eine Identifikation
  126.    an das Hauptprogramm (apid 0) schicken. Hierfür ist folgendes Format
  127.    definiert:
  128.    msgbuf[0]: ACC_ID
  129.    msgbuf[1]: apid des Absenders
  130.    msgbuf[2]: Länge der Meldung-16, hier also 0
  131.    msgbuf[3]: Versionsnummer und Protokollstufe
  132.    msgbuf[4] und msgbuf[5]: Zeiger auf Namen des Absenders
  133.    msgbuf[6]: Menünummer (menu_id)
  134.    msgbuf[7]: darf nicht verwendet werden (siehe ACC_ACC)
  135.    In msgbuf[3] wird im unteren Byte (msgbuf[3]&0xff) die höchste
  136.    Protokollstufe angegeben, deren Meldungen das Programm versteht. (Dies ist
  137.    unabhängig davon, welche Meldungen das Programm selbst verschickt. Der
  138.    Absender einer Meldung hat sicherzustellen, da₧ er nur Meldungen abschickt,
  139.    die der Empfänger versteht.) Das obere Byte ist für die Angabe einer
  140.    Versionsnummer in beliebiger Codierung vorgesehen.
  141.    Der Zeiger auf den Namen wird mit dem höchstwertigen Wort zuerst angegeben.
  142.    Der Name ist ein C-String, also eine Folge von Buchstaben mit einem Nullbyte
  143.    am Ende. Um Namenskonflikte zu vermeiden, sollten ausführliche Namen anstatt
  144.    kurzer Buchstabenfolgen verwendet werden. Der Name mu₧ an der angegebenen
  145.    Adresse jederzeit vom Hauptprogramm abfragbar sein, er darf also nicht
  146.    später entfernt werden.
  147.    Die Menünummer ist der von menu_register() zurückgegebene Wert. Accessories
  148.    mit mehreren Menüeinträgen müssen die Meldung ACC_ID mehrmals verschicken.
  149.    Accessories ohne Menüeintrag müssen -1 angeben.
  150.    Auch bei der Initialisierung eines Accessories, also bevor es auf einen
  151.    Aufruf wartet, mu₧ einmal diese Identifikation verschickt werden. Dies ist
  152.    für den Fall notwendig, da₧ ein XAcc-Hauptprogramm als Auto-Start-Programm
  153.    installiert wird (ab TOS 1.4). Anderenfalls wäre in diesem Fall keine
  154.    Kommunikation möglich.
  155.  
  156. 2) Als Antwort auf eine ACC_ID-Meldung schickt das Hauptprogramm ebenfalls eine
  157.    Identifikation an das jeweilige Accessory zurück. Diese hat denselben Aufbau
  158.    wie unter 1) beschrieben, lediglich die Menünummer entfällt und kann durch
  159.    einen beliebigen Wert ersetzt werden. Ebenso kann msgbuf[7] für eigene
  160.    Zwecke verwendet werden.
  161.  
  162. 3) Au₧erdem reicht das Hauptprogramm Accessory-Identifikationen an alle
  163.    bereits vorher angemeldeten Accessories weiter. Dazu dient die Meldung
  164.    msgbuf[0]: ACC_ACC
  165.    msgbuf[1]: apid des Absenders (also des Hauptprogramms)
  166.    msgbuf[2]: Länge der Meldung-16, abhängig von der Protokollstufe
  167.    msgbuf[3]: Versionsnummer und Protokollstufe des Accessorys
  168.    msgbuf[4] und msgbuf[5]: Zeiger auf Namen des Accessorys
  169.    msgbuf[6]: Menünummer des Accessorys (menu_id)
  170.    msgbuf[7]: apid des Accessorys
  171.  
  172. 4) Ein Accessory, das die ACC_ACC-Meldung vom Hauptprogramm bekommt, schickt
  173.    eine ACC_ID-Meldung an das so angemeldete Accessory (genau wie an das
  174.    Hauptprogramm).
  175.  
  176. 5) Wenn ein Accessory aktiv wird (z.B. wenn es im DESK-Menü angeklickt wird
  177.    oder wenn eines seiner Fenster aktiviert wird), schickt es folgende Meldung
  178.    an das Hauptprogramm:
  179.    msgbuf[0]: ACC_OPEN
  180.    msgbuf[1]: apid des Absenders
  181.    msgbuf[2]: Länge der Meldung-16, hier also 0
  182.    Nach Beendigung seiner Aktivitäten (z.B. nach Ausfüllen einer Dialogbox
  183.    oder nach Schlie₧en oder Desaktivierung eines Fensters) schickt es die
  184.    Meldung
  185.    msgbuf[0]: ACC_CLOSE
  186.    msgbuf[1]: apid des Accessorys
  187.    msgbuf[2]: Länge der Meldung-16, hier also 0
  188.    Das Hauptprogramm reagiert auf ACC_OPEN mit einer Restaurierung aller
  189.    veränderten Systemvariablen (soweit möglich und nötig), bei ACC_CLOSE
  190.    kann es den vorherigen Zustand wiederherstellen.
  191.    Auch Accessories sollten Systemvariablen nur nach Versenden von ACC_OPEN
  192.    ändern und vor Versenden von ACC_CLOSE wiederherstellen.
  193.  
  194. Nach der Initialisierung ist sichergestellt, da₧ jedes der beteiligten
  195. Programme die Identität aller anderen erfahren hat, entweder direkt
  196. durch ACC_ID oder indirekt durch ACC_ACC. Au₧erdem wird das Hauptprogramm
  197. über die Aktivierung von Accessories informiert. Eine Meldung über die
  198. Aktivierung eines Accessory an andere ist meist nicht erforderlich; falls
  199. dies zur Kommunikation zwischen zwei bestimmten Accessories nötig sein
  200. sollte, können private Meldungen (ab 0x800) dafür benutzt werden.
  201.  
  202.  
  203. Meldungen der Stufe 1:
  204. ----------------------
  205.  
  206. ACC_ACK = 0x500
  207. ACC_TEXT = 0x501
  208. ACC_KEY = 0x502
  209.  
  210.  
  211. 1) Übermitteln eines Textes:
  212.    msgbuf[0]: ACC_TEXT
  213.    msgbuf[1]: apid des Absenders
  214.    msgbuf[2]: Länge der Meldung-16, hier also 0
  215.    msgbuf[4] und msgbuf[5]: Zeiger auf Text
  216.    Der Text kann alle druckbaren ASCII-Zeichen (Code >= 32) enthalten, ferner
  217.    sind folgende Steuerzeichen definiert:
  218.    0x09  TAB (kann vom Empfänger auch als Leerzeichen interpretiert werden)
  219.    0x0A  LF  (wird vom Empfänger meist ignoriert)
  220.    0x0D  CR  (dient als Zeilenendmarkierung)
  221.    Andere Steuerzeichen sollten nur verwendet werden, wenn der Empfänger bekannt
  222.    ist. Der Text wird mit einem Nullbyte abgeschlossen.
  223.    Accessories sollten Texte nur dann verschicken, wenn sie selbst nicht aktiv
  224.    sind, da sonst das Hauptprogramm meist nicht auf den Text reagieren kann
  225.    (die Reaktion erfordert meist eine Bildschirmanzeige, die das Hauptprogramm
  226.    nur ausführen kann, wenn eines seiner Fenster aktiv ist).
  227.    Der Empfänger schickt nach der vollständigen Abarbeitung des Textes als
  228.    Antwort die Meldung
  229.    msgbuf[0]: ACC_ACK
  230.    msgbuf[1]: apid des Absenders (also des Empfängers des Textes)
  231.    msgbuf[2]: Länge der Meldung-16, hier also 0
  232.    msgbuf[3]: 0 wenn der Text ignoriert wurde, 1 wenn eine Aktion erfolgt ist
  233.    Bis zum Eintreffen dieser Meldung darf der Absender des Textes den Text
  234.    nicht verändern und auch keine weiteren Texte verschicken.
  235.    Der Empfänger sollte im Normalfall den Text wie eine Tastatureingabe
  236.    behandeln, ein Textverarbeitungsprogramm sollte ihn z.B. in den Text
  237.    einfügen.
  238.  
  239. 2) Simulieren eines Tastendrucks:
  240.    msgbuf[0]: ACC_KEY
  241.    msgbuf[1]: apid des Absenders
  242.    msgbuf[2]: Länge der Meldung-16, hier also 0
  243.    msgbuf[3]: Scan-Code der Taste und ASCII-Code (wie von evnt_keybd())
  244.    msgbuf[4]: Status der Shift-Tasten (wie von Kbshift())
  245.    Diese Meldung soll wie ein Keyboard-Event behandelt werden. Auf diese
  246.    Weise können z.B. Steuerbefehle von einem Accessory an das Hauptprogramm
  247.    geschickt werden. Dies setzt allerdings voraus, da₧ der Empfänger bekannt
  248.    ist, da es keine verbindlichen Konventionen zur Interpretation von
  249.    Tastenbefehlen gibt. Insbesondere ist es dem Empfänger überlassen, ob er
  250.    den Scan-Code oder den ASCII-Code verwendet (oder auch beide).
  251.    Der Empfänger quittiert auch diese Meldung nach ihrer vollständigen
  252.    Bearbeitung mit
  253.    msgbuf[0]: ACC_ACK
  254.    msgbuf[1]: apid des Absenders (also des Empfängers des Textes)
  255.    msgbuf[2]: Länge der Meldung-16, hier also 0
  256.    msgbuf[3]: 0 wenn ACC_KEY ignoriert wurde oder der gegebenen Befehl nicht
  257.               verstanden wurde, 1 wenn eine Aktion erfolgt ist
  258.    Mit dieser Meldung lä₧t sich z.B. eine Fernsteuerung eines Hauptprogramms
  259.    von einem Accessory aus realisieren.
  260.  
  261.  
  262. Meldungen der Stufe 2:
  263. ----------------------
  264.  
  265. ACC_META = 0x503
  266. ACC_IMG = 0x504
  267.  
  268. Diese Meldungen dienen zum Austausch von Bildern. Es werden nur die beiden
  269. im GEM-Standard definierten Bildformate verwendet, um die verarbeitenden
  270. Programme nicht zu kompliziert zu machen. Au₧erdem bieten diese beiden
  271. Formate genügend Flexibilität, um alle Anforderungen zu erfüllen.
  272.  
  273. 1) Versenden eines Metafiles:
  274.    msgbuf[0]: ACC_META
  275.    msgbuf[1]: apid des Absenders
  276.    msgbuf[2]: Länge der Meldung-16, hier also 0
  277.    msgbuf[3]: 1 für letzten Teil der Daten, 0 sonst
  278.    msgbuf[4] und msgbuf[5]: Zeiger auf Daten
  279.    msgbuf[6] unf msgbuf[7]: Länge der Daten (32 Bits als Langwort)
  280.    Die Bilddaten werden so versendet, wie sie auch in einer Datei stehen
  281.    könnten. Da die Länge der Daten recht gro₧ werden kann und vor allem
  282.    Accessories als Absender oft nicht genug Speicher haben, um ein ganzes
  283.    Bild zu speichern, kann ein Bild in mehreren Abschnitten versendet werden.
  284.    Der Empfänger mu₧ dann dafür sorgen, da₧ sie richtig zusammengesetzt
  285.    werden (er kann sie auch in eine Datei schreiben). Der letzte Teil
  286.    eines Bildes wird durch msgbuf[3]=1 gekennzeichnet. Zwischen den einzelnen
  287.    Teilen eines Bildes darf der Absender keine andersartigen Daten an
  288.    denselben Empfänger verschicken. In msgbuf[6] und msgbuf[7] wird jeweils
  289.    die Länge des gerade übertragenen Teils angegeben, nicht die Gesamtlänge.
  290.    Der Empfänger quittiert jeden Bildteil mit ACC_ACK wie bei Stufe 1
  291.    beschrieben.
  292.  
  293. 2) Versenden eines Bit-Image:
  294.    msgbuf[0]: ACC_IMG
  295.    ansonsten wie unter 1) beschrieben.
  296.  
  297.    
  298.  
  299. Beispiel für ein einfaches Accessory (in C):
  300. --------------------------------------------
  301.  
  302. Die folgenden Auszüge aus einem Accessory zeigen die notwendigen Routinen
  303. für ein Accessory der Protokollstufe 0:
  304.  
  305. ...
  306. #include   <portab.h>
  307. #include   <xacc.h>
  308. ...
  309.  
  310. send_id(ap_id,menu_id,destination)
  311. WORD ap_id,menu_id,destination;
  312. {
  313. WORD msgbuf[8];
  314.  
  315.    msgbuf[0] = ACC_ID;
  316.    msgbuf[1] = ap_id;
  317.    msgbuf[2] = 0;
  318.    msgbuf[3] = 0x1000;         /* Versionsnummer 1.0, Protokollstufe 0*/
  319.    *((char **)(msgbuf+4)) = "Name des Programms";
  320.    msgbuf[6] = menu_id;
  321.    appl_write(destination,16,msgbuf);
  322. }
  323.  
  324. main()
  325. {
  326. WORD ap_id,menu_id;
  327. WORD msgbuf[8];
  328.    ...
  329.  
  330.    ap_id = appl_init();
  331.    ...
  332.    menu_id = menu_register(ap_id,"  ACCESSORY");
  333.    send_id(ap_id,menu_id,0);
  334.    ...
  335.    while (TRUE)
  336.    {
  337.       evnt_mesag(msgbuf);
  338.       switch(msgbuf[0])
  339.       {
  340.          case AC_OPEN:
  341.             msgbuf[0] = ACC_OPEN;
  342.             msgbuf[1] = ap_id;
  343.             msgbuf[2] = 0;
  344.             appl_write(0,16,msgbuf);
  345.             ... /* hier steht die eigentliche Aktivität des Accessorys */
  346.             msgbuf[0] = ACC_CLOSE;
  347.             msgbuf[1] = ap_id;
  348.             msgbuf[2] = 0;
  349.             appl_write(0,16,msgbuf);
  350.             break;
  351.          case AC_CLOSE:
  352.             send_id(ap_id,menu_id,0);
  353.             break;
  354.          case ACC_ACC:
  355.             send_id(ap_id,menu_id,msgbuf[7]);
  356.             break;
  357.       }
  358.    }
  359. }
  360.  
  361.  
  362. Auszug aus einem Hauptprogramm der Stufe 0:
  363. -------------------------------------------
  364.  
  365. ...
  366. #include <portab.h>
  367. #include <xacc.h>
  368. ...
  369. #define MAXACCS 6
  370. WORD acc_cnt = 0;
  371. WORD acc_apid[MAXACCS];
  372.  
  373. acc_init(ap_id,acc_id)
  374. WORD ap_id,acc_id;
  375. {
  376. WORD i,msgbuf[8];
  377.  
  378.    if (acc_cnt < MAXACCS)
  379.    {
  380.       acc_apid[acc_cnt] = acc_id;
  381.       msgbuf[0] = ACC_ACC;
  382.       msgbuf[7] = acc_id;
  383.       msgbuf[1] = ap_id;
  384.       msgbuf[2] = 0;
  385.       for (i = 0; i < acc_cnt; i++)
  386.          appl_write(acc_apid[i],16,msgbuf);
  387.  
  388.       msgbuf[0] = ACC_ID;
  389.       msgbuf[3] = 0x2500;  /* Version 2.5, Protokollstufe 0 */
  390.       *((char **)(msgbuf+4)) = "Hauptprogrammname";
  391.       msgbuf[6] = 0;      /* oder etwas anderes */
  392.       msgbuf[7] = 0;      /* oder etwas anderes */
  393.       appl_write(acc_apid[acc_cnt++],16,msgbuf);
  394.    }
  395. }
  396.  
  397. main()
  398. {
  399. WORD ap_id;
  400. WORD msgbuf[8];
  401.    ...
  402.    ap_id = appl_init();
  403.    ...
  404.    while (TRUE)
  405.    {
  406.       evnt_mesag(msgbuf);
  407.       switch(msgbuf[0])
  408.       {
  409.          case ACC_ID:
  410.             acc_init(ap_id,msgbuf[1]);
  411.             break;
  412.          case ACC_OPEN:
  413.             /* z.B. Systemvariablen auf 'normale' Werte setzen */
  414.             break;
  415.          case ACC_CLOSE:
  416.             /* z.B. Systemvariablen auf eigene Werte setzen */
  417.             break;
  418.          ...
  419.       }
  420.       ...
  421.    }
  422. }
  423.  
  424.  
  425. Programme, die das XAcc-Protokoll verwenden (Stand April 1989):
  426. ---------------------------------------------------------------
  427.  
  428. Das Textverarbeitungsprogramm That's Write ist ein Hauptprogramm der
  429. Stufe 2, es akzeptiert Texte und Bit-Image-Daten. Au₧erdem kann man
  430. mit That's Write Texte an Accessories verschicken, indem man den Text
  431. als Block markiert und das gewünschte Accessory über Tastatur aufruft.
  432. In diesem Fall erhält das Accessory, falls es mindestens Stufe 1
  433. versteht, eine ACC_TEXT-Mitteilung, jedoch keine AC_OPEN-Mitteilung.
  434. Wenn das Accessory den Text nicht verarbeiten kann, oder wenn es nur
  435. Stufe 0 versteht, wird eine AC_OPEN-Mitteilung verschickt, wie wenn
  436. kein Block markiert war. So wird sichergestellt, da₧ das Accessory bei
  437. einem Aufruf über Tastatur auf jeden Fall aktiviert wird.
  438.  
  439. Die Adressverwaltung That's Address ist ein Accessory der Stufe 1. Wenn
  440. sie mit ACC_TEXT aufgerufen wird, interpretiert sie den übergebenen Text
  441. als Suchwort und gibt die dazugehörende Adresse ebenfalls mit ACC_TEXT
  442. an das aufrufende Programm zurück. Ebenfalls möglich ist eine manuelle
  443. Übergabe einer Adresse an das Hauptprogramm, indem That's Address mit
  444. F5 verlassen wird.
  445.  
  446. Der TOS-Kommandointepreter ATC-Command ist ein Accessory der Stufe 0.
  447. In der momentanen Version ist eine Datenübergabe nicht möglich. Spätere
  448. Versionen werden jedoch Befehle entgegennehmen und Ergebnisse
  449. zurückgeben.
  450.  
  451.  
  452. Fragen und Erweiterungsvorschläge bitte richten an:
  453. ---------------------------------------------------
  454.  
  455. Konrad Hinsen
  456. Gelderner Str. 22b
  457. D-5170 Jülich
  458.  
  459. Bitnet: CD010HI@DACTH11
  460. FidoNet: Konrad Hinsen @ 2:242/3.3
  461. MausNet: Konrad Hinsen @ AC
  462.